\chapter{Implementation}
This chapter opens the implementation part of this thesis. The goal of this thesis is to design a software that will experimentally test proposed solution of the tasks described in the theoretical section with the documents received from CEZ, a.s. company. Requirement has been proposed in the theoretical section, this chapter includes the analysis of a proper architecture and its composition. The following chapters of the implementation part describes each module in greater detail and enlist problems that has been encountered.

\section{Decomposition}
 The application can be decomposed into smaller parts. Each requirement should be implemented in a separate modules. This will increase the extensibility in the future. Some of the requirements can change in time. Separating each task in a separate module will decrease a change of having to change the implementation of others. This justifies to use decomposition and implementation of each task set in the theoretical section into modules. It results into these parts:

 \begin{itemize}
	\item \emph{Text Extraction} - Will receive any of the document provided from CEZ a.s., will extract a plain text from it, will store it in a file and will return reference to that file. The supported document types will be Microsoft Word, PowerPoint, PDF. During the extraction process the structure of the text must be intact. To reach this goal some post processing will be needed.
	\item \emph{Linguistic processing} - Will receive a plain text file and will invoke a linguistic text processing. In this case it will invoke \emph{Treex}. However this module could be switched by any of linguistic processing tools, for example \emph{Stanford CoreNLP} and others. To support extensibility and load balancing, it will invoke the linguistic processing remotely. To support this feature, module will be invoked via RMI.
	\item \emph{Process linguistic result} - Treex writes results in \emph{CoNNL}\cite{Conll} format. The modules will get a file containing the results of linguistic processing in this format. It will parse the result and will create an internal representation of the document, that will contain all linguistic informations about the document such as dependency trees of the sentences and for each word its morphological tags, lemma, original text etc. It will return object that will contain the internal document representation to allow IE based on specific patterns.
	\item \emph{IE module} - This module will receive an internal document representation that will be created in the previous module and search configuration file. Search configuration file will contain information about the search patterns. The module will process the document based on the search configuration and will extract triples and terminology expressions with their frequencies. The module will return an object that will contain set of extracted triples and set of terminologies.
	\item \emph{DB module} - This module will provide access to the virtuoso database, or any other semantic database that will implement specific interface. This module will create a graph from information extracted from a document and store them in the database. On top of that, the module will enable to search for a document based on parts or full triples and terminologies. Besides document search, it will allow to search for triples and terminologies. It will return any information that is stored in the database based on the type of a request. The module will use Virtuoso JDBC driver to connect remotely to the Virtuoso database.
	\item \emph{GUI} - will provide interaction between the application and user. It will process user requirements and will display results.
\end{itemize}

The difference between the search done \emph{IE} and \emph{DB} module is that \emph{IE} module searches in the result of the NLP and extract information and the \emph{DB} module searches in the knowledge graphs stored in the database. Each of the module fulfill one task and cannot be decomposed into smaller tasks nor joined with other module.


\section{Architecture}

As described in the requirements section in the theoretical section. The application would as a web service is better then a stand alone application. By closely examining the modules, 3 layers can be distinguish.\begin{itemize}
	\item Data layer - Virtuoso database
	\item Business logic - Text extraction, NLP, IE
	\item Presentation layer - GUI
\end{itemize}

It meets with a 3-layer system architecture pattern, but the proposed is rather simple application then a large system. Therefore its more suitable to be described as MVC (Model-View-Controller\cite{MVC}) application architecture pattern. But the system is still not exactly the MVC by the book. Model by the definition of MVC is used for data layer and the defined modules should be considered as business layer than data layers. The application architecture is shown on the figure\ref{fig:Architecture}. \emph{View} and \emph{Controller} will be implemented in a same model, they do not need to be in a separated module explicitly. There will be 5 modules in the \emph{Model} component. \emph{Treex} and Virtuoso database can be deployed on different server and are marked in the architecture as remote entities.

\begin{figure}[ht]
\centering
\includegraphics[width=0.5\textwidth]{./img/architecture.png}
\caption{Software architecture}
\label{fig:Architecture}
\end{figure}

\subsection{Model}
Each of the module implement part of the requirements and represent the application's domain logic. To provide extensibility, each of the modules will be implementing interfaces. Any future module that will implement any of the interface can replace the module. it will minimize the chance of affecting implementation of other modules. Modules that are part of the \emph{Model} component:
\begin{itemize}
	\item \emph{Text Extraction}
	\item \emph{Linguistic processing}
	\item \emph{Process linguistic result}
	\item \emph{IE module}
	\item \emph{DB module} 
\end{itemize}


\subsection{View and Controller}
View component will allow user to interact with the application. The application needs to be accessible via Web browser, since domain logic will be written in \emph{Java}, use of \emph{Servlet} is almost obligation. To simplify interaction between the UI and the rest of the application an appropriate Java framework that will allow to create UI and to embedded it into the application. One solution might be a \href{http://www.gwtproject.org}{GWT} (Google Web Toolkit) which is development toolkit for building and optimizing complex browser-based applications. Another solution is \href{https://vaadin.com/home}{Vaadin} that is Java framework for building modern web applications. Both options are suitable. \emph{Vaadin} is relatively new, it focuses mainly on server-side architecture and uses GWT for rendering the resulting web page. \emph{Vaadin} has been selected because it uses GWT and it is always good to learn a new technology. As mentioned earlier Controller can be any class that will interconnect modules, processes user requests and pass them to the domain logic. In the opposite direction it will receive updates from the domain logic and will fill the UI with a new data.